Within typical multiprocessor systems, the system bus is used to communicate commands to be processed by the processors. Depending on the state of a given PU (processor unit) or other bus master to which the request is directed, the response to a given command may be an indication that this command cannot be processed at this time because of some conflicting condition. The requesting PU must then “retry” the command. Attempting to immediately retry will normally cause a livelock condition, thereby degrading the performance of the bus.
A prior art known approach to alleviating this problem is to have the requesting unit delay a “random” amount of time before reissuing the command. The problem with this approach is that, in some situations, the random time may be too soon and, in other operationally critical situations, the random time may be too long.
It would be desirable that the retry interval be related to the type of command to be executed and/or other factors that could affect the likelihood that the request for action be completed at the time of the retry. It would further be desirable that the retry mechanism could provide dynamic adjustment of the retry interval based upon past experience for different types of commands and/or for given associated bus masters.